Columbia Kermit/kermit.zip/newsgroups/misc.19950528-19950726/[e-mail]_Sun May 28 12:43:13 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA21379
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Tue, 30 May 1995 03:24:13 -0400
Received: by apakabar.cc.columbia.edu id AA05590
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Tue, 30 May 1995 03:24:11 -0400
Path: news.columbia.edu!panix!zip.eecs.umich.edu!newshost.marcam.com!news.mathworks.com!uhog.mit.edu!bloom-beacon.mit.edu!gatech!swrinde!news.dell.com!pmafire!mars.poci.amis.com!cwis.isu.edu!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit under MS-Windows
Message-Id: <[e-mail]>
Date: 28 May 95 18:43:13 MDT
References: <3q04p0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <3qau77$[e-mail]>
Organization: Utah State University
Lines: 48
Apparently-To: [e-mail]

In article <3qau77$[e-mail]>, [e-mail] (John W. Manly) writes:
> What we have diagnosed in this "unable to find hardware, using BIOS"
> situation is that it's a timing related thing.  If we try to access the port
> via a SET PORT command or a CONNECT right after Kermit starts up, it fails
> fairly reliably.  But if we wait two or three seconds after Kermit starts,
> the connection works just fine.  It looks for all the world as if Windows
> is just taking to long to "let go" of the serial port (or initialize its
> emulation).
>
> The really frustrating thing is that you can't just put a PAUSE or WAIT
> command in the MSKERMIT.INI file to cause the necessary delay -- those
> commands don't work either -- Kermit just zips by them as if they weren't
> there during this period before the serial interface is enabled.
>
> So what we finally did, for those machines where this happens (and it happens
> by no means to all of them) is insert a "Press RETURN to continue" message
> at the beginning of the MSKERMIT.INI file, which seems to provide enough time
> for Windows to do whatever it needs to do for Kermit's SET PORT command to
> work.  I thought about just writing a counting loop, but decided it wasn't
> worth the hassle since I would have to worry about the relative speed of
> the machine to make sure it didn't take too long on slow machines, but didn't
> complete too quickly (before SET PORT would work) for fast ones.
>
> - John W. Manly  <[e-mail]>  Amherst College
-----------
    I repeated the exercise here too. I happen to use a Hayes ESP serial
board with its Windows drivers. Two observations. First, indeed Windows
declines to cooperate in sampling the serial port for IBM-PC-UART-ness during
the first attempt. My system says MSK can't validate the IRQ for COM1.
Secondly, PAUSE opens the serial port because the command was designed to
work with modem scripts and thus keep echoed material showing on the screen.
SLEEP does the same waiting without touching the comms channel.
    Then, both PAUSE and SLEEP do work fine in a Kermit startup file.
What you stated as zipping right through was really Windows starting Kermit
from some gosh awful place, such as \Windows, and MSK never saw it's
initialization file(s). Verify by SHOW MACRO or SHOW VARIABLE to see only
the built-ins, or stick in a ECHO HELLO in a startup file.
    The way I force Windows to let MSK startup normally is in the MSK
PIF file I add the phrase  -f drive\path\mskermit.ini (choose your favorite
file) in the "startup options" box. That is the command line passed to MSK
and then MSK knows how to find the file(s) at startup time.
    Thus, there are at least two things happening here. One is the
mysterious startup directory available to Kermit, solved by stating the
fully qualified name of the startup file on the line which invokes Kermit.
The other is Windows appears to be sitting on the serial port until bumped
hard twice. You may want to experiment with serial port settings in win.ini
to see if Windows can be told to stay away from the port.
        Joe D.